home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
BBS Toolkit
/
BBS Toolkit.iso
/
remote
/
vd170r1.zip
/
VD.DOC
< prev
next >
Wrap
Text File
|
1993-03-06
|
31KB
|
985 lines
PRELIMINARY DOCUMENTATION PRELIMINARY DOCUMENTATION PRELIMINARY DOCUMENTATION
THIS DOCUMENTATION IS NOT FINISHED BUT WAS INCLUDED ANYWAY IN ORDER TO GET THE
NEW RELEASE OUT A.S.A.P. PLEASE REFER TO THE ENCLOSED VD.CFG FILE FOR INFO ON
SETTING UP VALIDOOR.
V V A L III DDDD OOOOO OOOOO RRRR
V V A A L I D D O O O O R R
V V AAAAA L I D D O O O O RRRR
V V A A L I D D O O O O R R
V A A LLLLL III DDDD OOOOO OOOOO R R
Documentation
Version 2.00
Copyright (c)1989-93, Cabell B. Clarke Jr.
ALL RIGHTS RESERVED.
The Boot Factory BBS
--------------------
FidoNET 1:264/19
3/12/24/96/144 v32bis
(804) 262-9289
Disclaimer
This software is sold "AS IS". It is not guaranteed to work at all. If it
trashes your system or ruins your life, you have been warned. I am not
responsible for any damages incurred from the use or misuse of this software.
ValidOOR is a User Validation Door written for the RemoteAccess Bulletin Board
System. ValidOOR allows Sysops to have their systems call users back in order
to verify that they have left a valid phone number for the sysop's records.
Validoor then updates the user's BBS record so he can call right back and have
access to the BBS. This saves the sysops time and trouble of manually
validating users. Be forewarned *** ValidOOR is NOT designed to keep unwanted
users off of your BBS. It will not keep a determined person off.*** It will
validate your users so you don't have to manually do that.
ValidOOR is being released as Shareware. This means you are free to evaluate
the program for 30 days. If it meets your needs, you are then expected to
register your copy by sending me a registration fee. Registering ValidOOR
entitles you to all minor releases of Version 1 of ValidOOR (1.00-1.99). It
also grants you access to the ValidOOR Support Forum on my BBS which contains
ValidOOR utilities. Users who register Version 1 of ValidOOR are entitled to
Version 2 free of charge. There will possibly be an upgrade fee to version 3
but remember I originally said the same thing about version 2.
Unregistered versions of ValidOOR will have a 30 second delay built-in to the
program. The KEY file will eliminate this delay and inform the rest of the
world that you have registered your copy.
Please register ValidOOR. This program has been in development since December
of 1988, and has cost me a lot in the process. Support the Shareware concept.
Registration of ValidOOR allows you to run ValidOOR on one computer system
ONLY.
In order to register ValidOOR, see the LICENSE.DOC file for an order entry
blank. Fill out the form and send with the registration fee to:
Cabell Clarke
5513 Cottage St.
Richmond, VA 23228
Your KEY file will be sent to you via FidoNet mail, or US Mail... whichever is
convenient. Allow 2 weeks for processing.
A Note about multi-line systems
At this time, VD does not support file/record locking so it cannot be reliably
used on a multi-node bbs on more than one node. It should work fine on one
node however. I would like to add file/record locking to VD in the future.
Send Code<tm>.
Getting Started
In order to get going with VD, first you need to unzip all of the files into
your BBS or ValidOOR directory. See the file PACKING.LST which accompanied
the VD ZIPchive to make sure you have all of the necessary files. I recommend
printing this documentation. I also recommend printing the VD.CFG file as it
contains helpful hints for setting up the configuration file in it's comments.
Modify (or create) the .MNU .ASC .BAT files included to suit your needs. The
enclosed are samples only which I run on my system. You are welcome to modify
my files for your own use keeping in mind that my setup may be somewhat
different from yours.
Rename the vd###.exe to VD.EXE
Environment Variable
You can run ValidOOR in its own sub-directory by setting the ValidOOR
environment variable to that sub-dir. Two valid examples are:
set validoor=d:\validoor\
set validoor=c:\bbs\vd
VD will find its sub-dir with or without the trailing backslash. You should
place your vd.cfg and vd.key (registered users) in this sub-dir. If you want
to place your executable files in this directory you should also include it in
your path like this:
path=c:\bbs\vd
Setting Up vd.cfg
The VD.CFG file contains all of the important parameters necessary to run VD.
Please remember that any line which begins with a per-cent (%) is a comment
and may be removed, however, if you remove comments, you are on your own.
VD.CFG is well-commented and should be self explanatory in setting it up.
Just load it into your text editor. Make sure that there are no comments on
the lines which contain parameters. Also make sure that you only have one (1)
space between the Variable Descriptor and the variable itself like this:
ModemSuffix &M4
^
one space here
NOTE:
In the many versions of ValidOOR there have been several vd.cfg file formats.
In this version, there are some new descriptors so it is suggested that you
modify the configuration file included in this archive to suit your setup.
Make sure the vd.cfg file you are using is compatible with your version of VD.
Variable descriptors in vd.cfg
---
%
- the percent sign is a comment and must be placed in the first column of the
line that you wish VD to ignore. Do not place a '%' on the same line after a
variable descriptor or the program will not operate correctly.
---
SysopName
- Your name should go here. This is required. Example:
SysopName Cabell Clarke
---
YourCitySt
- Tells VD what city and state your BBS resides in to notify the user where
the call will be originating so the user can tell VD if VD needs to dial a 1
to reach the User.
---
Port
- Port tells VD which communications port you are using. Valid ports are 0-3
where port 0 = COM1 etc. If you are using COM1 for your modem you would need:
Port 0
---
DialPrefix
- This is the prefix that tells your modem how to dial out. Mine looks like
this:
DialPrefix ATDT
---
AreaCode
- This Variable is used to tell VD which area code(s)you can place a local
call to. You may have up to 5 local area codes in VD.CFG... for instance
someone who lives in Washington DC might have a VD.CFG which looks like this:
AreaCode 202 <-- your area code first
AreaCode 301
AreaCode 703
This is because he does not need to use an area code to dial any of these
three areas. Maximum of 5 local area codes supported at this time. Make sure
that your own area code is listed in the file first.
---
InvalidExchange
- This descriptor tells ValidOOR about 3 digit exchanges which are invalid
like 911 in some areas. ValidOOR treats these exchanges very harshly so use
them with care. If a user attempts to get ValidOOR to dial a number with one
of these exchanges, ValidOOR will disconnect them from the system. You may
use a maximum of 10 of these. Examples:
InvalidExchange 911
InvalidExchange 411
---
PreDialLDCode
- This descriptor is the prefix used by your phone system for dialing a long
distance call. The default value is 1.
PreDialLDCode 1
---
NotFirstDigit
- This descriptor tells ValidOOR about invalid first digits in phone number
exchanges. ValidOOR will refuse to dial numbers with these digits first. I
use the two below.
NotFirstDigit 0
NotFirstDigit 1
---
Phone
- This variable is used to tell VD how your BBS saves the user's phone number.
When a new user logs on if you ask for both Home Phone Number and
Data/Business Phone number then your VD.CFG file would need the following:
Phone HomePhone
Phone DataPhone
If you only ask them for their Home Phone Number then your VD.CFG file would
only need this:
Phone HomePhone
---
YourCodeLD
- This one will allow you to tell VD not to strip your area code from long
distance numbers in your area code - I call this Ed Marquis mode <grin> since
it was his requirement which prompted the addition of it.
YourCodeLD NoStrip
If you don't use this VD will default to stripping them anyway.
---
LongDistance
- The LongDistance descriptor enables/disables Long Distance calling. If you
do not want VD to make a long distance call you would have the following in
your VD.CFG file:
LongDistance NoLDCall
If you want VD to make a Long Distance call (whether using slots or not), you
would use:
LongDistance LDCall
This one would make long distance calls at any time or allow you to use the
slots below if you want to.
---
LDSlotDefault
- This variable tells VD the default slot of time for making long Distance
calls. This slot is always in effect unless commented out or overridden by a
daily slot. The correct usage is:
LDSlotDefault <starttime> <stoptime>
Example:
LDSlotDefault 2200 0700
The above would allow your system to make long distance calls between 10pm and
7am on all days providing the LongDistance variable is enabled as shown above.
---
LDSlotSun
LDSlotMon
LDSlotTue
LDSlotWed
LDSlotThu
LDSlotFri
LDSlotSat
- These are the daily slots which will override the default slot above. The
syntax for these is the same as above:
LDSlotSat 0000 2359
LDSlotSun 0000 1659
The two examples above would allow your system to call long distance all day
Saturday and all day before 5pm on Sunday. The rest of the days would use the
default slot above.
---
MaxAttempts
- This variable tells VD how many times to attempt to call a user with NO
CONNECT! If you only wanted to try twice you'd have:
MaxAttempts 2
VD will only call once if a connection is made. This is hard-coded into the
program and cannot be modified.
---
ModemTimeOut
- This is the number of seconds you want VD to wait for a carrier before
recycling. NOTE: For maximum efficiency You should also set this value in
register S7 of your modem in your modem initialization string. (S7=45). See
ModemInit below.
ModemTimeOut 45
---
UserTimeOut
- This is the number of seconds to wait for input from the user before timing
out due to INACTIVITY.
UserTimeOut 40
---
ModemInit
- This is the string that you want VD to use to initialize your modem. I use
this for my HST:
ModemInit AT S0=0 E0 X6 S7=45|
Note the s7=45 which is the same as the 45 in the ModemTimeOut variable above.
If you want VD to ignore result codes use an X0 in this string but remember if
you use an X0, all Bad Number/VOICE connect processing will be eliminated.
The "|" character adds a carriage return to your string.
---
ModemReset
- This variable tells VD whether you want to reset your modem before you
initialize it. If you want to reset it enter the string you want to send to
it like this:
ModemReset ATZ|
Note the '|' sends a carriage return.
---
LogPath
- This is the path to your VD Log File where a log of VD's activities are
kept. I use:
LogPath d:\qbbs\validoor.log
---
LogStyle
- this allows you to make your log look like an Opus/Binkley or FrontDoor
style log. Valid descriptors are:
LogStyle BINK
LogStyle FD
---
ExitInfoPath
- another optional descriptor which tells VD where it can find your
EXITINFO.BBS file. Requires full path and filename. Default is current
directory.
ExitInfoPath c:\bbs\exitinfo.bbs
---
UserPath
- this descriptor is here for VD_Pack to use to find the Users.BBS file.
ValidOOR will ignore it. Again a full path and filename is required.
UserPath c:\bbs\users.bbs
---
UserDir
- This is the Path and filename of your User Directory where the names and
phone numbers of validated users are stored. This is to make sure that users
cannot be validated twice at the same phone number. I use:
UserDir c:\bbs\validoor.dir
This is an optional feature and may be disabled by commenting it out.
---
BadNumber
- This is the full Path and filename to your Bad Phone Number Control file.
This file is where any phone numbers that ValidOOR senses to be VOICE connects
will be written and therefore prevented from ever being dialed by ValidOOR
again. If you wish you may use your BBS PHONENUM.CTL file for this,
remembering that any numbers that end up in PHONENUM.CTL will never be dialed
by ValidOOR. Usage as follows:
BadNumber d:\qbbs\badnumbr.ctl
BadNumber d:\qbbs\phonenum.ctl
If you do not wish to use this feature, simply comment it out. It is
optional.
---
EditPhone
- This allows a user to edit his phone number from within ValidOOR. It has
three parameters which do the following:
EditPhone 0
Do not allow user to edit phone number
EditPhone 1
Allow user to edit phone number
EditPhone 2
Allow user to edit phone number & update Users.BBS
---
ModemSuffix
- This is for modems like the HST which can use a suffix after the phone
number to cause a certain type of connection to be made. Comment it out if
you don't need it. With my HST I use:
ModemSuffix &M4
---
WaitTime
- This is the number of seconds to wait before the first attempted call and
between each attempted call. I suggest using 10 seconds:
WaitTime 10
---
OffHook
- This is the string you wish to use to take your modem offhook during the
above WaitTime to keep an incoming call from messing up VD's validation
attempt. I use this for my HST:
OffHook ATH1|
---
OnHook
- This string puts the modem back on hook after WaitTime before a call is
made. I use:
OnHook ATH0|
---
ValidGoodbye
- This is the full path and filename to a text file that you wish to be
displayed to the user who has been validated successfully. I use:
ValidGoodbye c:\bbs\text\validgb.asc
---
InValidGoodBye
- This is the path to a text file to be displayed to a user that is not
validated successfully. Mine is:
InValidGoodbye c:\bbs\text\invaldgb.asc
---
LDGoodbye
- This file will be displayed to a user when Long Distance calls have been
disabled. I use:
LDGoodbye c:\bbs\text\ldgoodby.asc
---
HitAnyKey
- This is for High-Speed modem users who run with the port locked. It places
a "Hit ANY Key" at the end of each 'goodbye' file above, so that the user will
see all of the file before the modem disconnects. If your port is not locked
use:
HitAnyKey No
If your port is locked use:
HitAnyKey Yes
---
SlowModem
- This descriptor enables commands sent to the modem slowly for modems that
cannot respond to an initialization string sent at full blast! Usage:
SlowModem On
SlowModem Off
---
ForeGround
BackGround
- Color Attributes for Normal Activity Window
---
MessageForeGround
MessageBackGround
- Color Attributes for Message Bar
---
StatusForeground
StatusBackground
- Color Attributes for Status Info
---
WindowForeGround
WindowBackGround
- Color Attributes for Status Window
I use these:
ForeGround 7
BackGround 0
MessageForeGround 4
MessageBackGround 7
StatusForeground 15
StatusBackground 3
WindowForeGround 0
WindowBackGround 3
---
SecLevel
- This is the security level you want to set validated users to:
SecLevel 5
If you do not want Validoor to set any levels, then comment out this line.
---
AFlag
BFlag
CFlag
DFlag
- These descriptors define the bit masks for the user flags. You set them just
like you would in your user editor. If you don't want VD to mess with user
flags, just comment them out. Using the letter 'n' in place of any bit will
cause VD to leave that bit untouched.
AFlag XXXX---n
% BFlag --------
CFlag X-X-X-Xn
% DFlag --------
Above the AFlag and CFlag would be set like above for a user who passes
validation successfully. The BFlag and DFlag would not be touched. Bit 8 on
both AFlag and CFlag would be untouched by ValidOOR.
---
TimeLimit
- Use this to set the new time limit for the user after he is validated.
TimeLimit 60
would give a newly validated user 60 minutes. This is useful if you let newly
validated users back into your system after you call them (on your nickel).
Comment this out to disable this feature.
---
TwitLine
- This can be a line of text displayed to a user you have just 'Twitted' with
the <F10> Twit key.
TwitLine Please Call some other BBS
The default twitline if you don't use this descriptor is:
"System Error - Disconnecting..."
---
ValidShell
- This is used to get your system to run external programs after validating
Users. You may have up to 10 ValidShells which are executed in the order they
are listed in VD.Cfg. Example below would run the program Postit.Exe
ValidShell Postit.Exe -t@UserName -f"Sysop" -mtext.txt
NOTE the use of the VDVariable @UserName. ValidOOR will replace this variable
with the user's name. See VDVariables section for details:
---
UserComment
- This will put a comment in the Usersxi.bbs file. It also understands
VDVariables.
UserComment ValidOOR v@Version at @VD_Time on @VD_Date
---
Language
- The name of your ValidOOR language file. Use a full path if you are not
using the environment variable. The ASC/ANS extension is added so do not put
an extendion on it. If not used, ValidOOR will default to VD-LANG. Example:
Language VooDoo
%%% End of VD.CFG %%%
In ALL of the above descriptors the CASE is not significant but it may be in
your modem commands depending on your modem.
The default filename for your configuration file is VD.CFG. You may also tell
Validoor the name of your configuration file on the command line when you run
it like this:
vd myvd.cfg
or
vd yourvd.cfg
You should NOT include a Path to your vd.cfg on the command line unless you
are not using the ValidOOR environment variable.
VD_Variables
------------
VD_Variables are output variables that you can use in interfacing VD with the
caller as well as the outside world. Generally they work like this. When VD
encounters a vd_var it will replace that vd_var with a corresponding piece of
data from within ValidOOR. These work in several places in ValidOOR such as
in the User Comment field, as well as the ValidShell execution. Some of them
are also VERY useful in the language file as you will see when you examine the
enclosed language file.
There are a total of fourteen vd_vars. They and their functions are listed
below:
@UserName User's First & Last name
Format: Ken Givens
@User_Name Same as @UserName except
Format: Ken_Givens
@Version ValidOOR Current Version
@VD_Date Current Date
@VD_Time Current Time
@LDCode PreDialLDCode from vd.cfg
@Sysop SysopName from vd.cfg
@VD_EOL inserts CR/LF characters (careful with this)
@Home Key for selecting HomePhone from menu
@Data Key for selecting DataPhone from menu
@Abort Key for selecting Abort ValidOOR from menu
@Edit Key for selecting to edit phone number from menu
@Yes Key for selecting Yes response
@No Key for selecting No response
The last few which are selection keys from the menu, etc. are particularly
useful in the language file. If you use them there, anytime you change the
key definitions in vd.cfg, the new definitions will automatically be plugged
into the language file at runtime. This results in less work for you.
Interfacing ValidOOR
There are several ways you can run ValidOOR on your system. I use a type 40
command in my TOP.MNU with flag D1 set ON (X) to force all new users into the
validation menu. After successful validation I set the D1 flag back off (-)
and then when they hit TOP.MNU the 1st type 40 command will be ignored due to
the flag not being ON and the TOP.MNU will execute normally. I have included
my menus in this archive to give you an idea as to how I do it.
You can also just use a Type 2 command to let your users access VD that way...
it is up to your personal preference as to how you get your users into
ValidOOR. Be creative :-). That is why the system has been designed to be so
open-ended.
Once the user selects ValidOOR, the BBS should exit via type 15 or type 7 EXIT
to run ValidOOR. See your BBS documentation for an explanation of Type 7 and
15 Exits. I use a type 15 EXIT to my RunRa.Bat file which then calls my
Validate.Bat which I have included here. When the Validate.Bat file runs it
loads ValidOOR which then initializes the FOSSIL driver, and does some setup
things - reads VD.CFG which you the sysop must set up, and then it looks for
EXITINFO.BBS.
At this point, if you have opted to use a User Directory File to prevent
duplicate phone numbers, VD will check for the existence of this file which it
creates if not found. If you comment out the UserDir descriptor in VD.Cfg, no
dupe checking will be performed.
ValidOOR also creates a log file and appends info to it so you can keep track
of it's activities.
ValidOOR can be set up to use either the business/data phone number, the
home/voice phone number or both phone numbers that the user entered during his
initial login depending on how you choose to set up your BBS. You can also
optionally allow the user to edit his phone number in two different ways - 1)
temporary edit for calling which is not saved, or 2) edit which is saved into
the DATAPHONE field in the users.bbs file. If you are going to allow your
users to edit their number from within ValidOOR it is highly recommended that
you use option 2 and save the edits. This is more secure.
ValidOOR will prompt the user to select which of the two numbers his modem is
currently connected to and give him an option to abort the process should he
so desire. After this selection is made, ValidOOR will ask him if a 1- should
be placed in front of the number for a long distance call. If you choose not
to let VD make long distance calls, the user will not be called and a file
explaining the situation can be displayed (See VD.CFG descriptor LDGoodbye.
If Long distance calling is enabled, VD will place the 1- in front of his
number and continue with the process.
If all files are present and everything went properly, ValidOOR will inform
the user that he is about to be validated and display the following line:
"Prepare for an incoming call. If your modem will not auto answer, when you
see the RING on screen type ATA and hit <Enter>."
Then ValidOOR prompts him to hit <ENTER> when he is ready to begin. When the
user hits <ENTER> ValidOOR will disconnect him, take the phone off the hook,
and wait a pre-defined number of seconds (WaitTime in VD.CFG). The ValidOOR
will put the modem back on the hook and call the user at the same baud rate
that he used to log into the BBS. The number of "Non-Connect" attempts can be
set up in VD.CFG but the system, after one connection is made, will not make
another attempt to call.
If your modem is capable of sensing a VOICE connect, and your modem
initialization string has the proper value sent to it to enable this feature,
then when ValidOOR senses a VOICE connection and you have a path in the
'BadNumber' descriptor uncommented, ValidOOR will abort and write this phone
number to a BadNumber Control file. Then VD will never attempt to call this
number again. You may use your PHONENUM.CTL file in your BBS for this if you
fully understand that no one ever be able to use this number to log in to your
BBS as a new user again. Using X0 in your Modem Initialization string will
totally disable modem result codes and then ValidOOR will ignore all of this
entirely.
When the connection is successful, ValidOOR will display a brief message
something like this:
ValidOOR v1.60
and then display the SysName1 and SysName2 messages that you set up in VD.CFG.
Next VD prompts the user to enter his password. He gets three tries before
ValidOOR gives up and disconnects. An Inactivity timer which is configurable
in VD.CFG will disconnect him if he falls asleep. If he fails to enter the
proper password (from EXITINFO.BBS) for whatever reason, the system will
disconnect him and exit with an errorlevel 2. Your batch file can then
process the errorlevel accordingly. An appropriate entry will be written to
the log.
If he is successful, then ValidOOR will exit with an errorlevel 0. Your batch
file can process accordingly. Also an entry will be written into the log file
to let you know what happened. If you have selected to do so in VD.CFG, and
are running from a type 15 exit, ValidOOR will update the user's security and
user flags in the EXITINFO.BBS.
NOTE: It is necessary to reload your BBS after VD exits using the command:
RA -R
in order for the changes in security level and user flags to take place. If
you do not reload your BBS the updates will NOT be written to the USERS.BBS
file. See my SPAWNBBS.BAT file for an exact example as to how this should be
done.
Function Keys
Some function keys are available to the sysop while a user is online.
<F1> - Chat
- Pressing this key will put you in Chat Mode with the caller. Hitting <ESC>
will exit the chat mode.
<F2> - DOS
- This key will allow you to shell to DOS via your Comspec variable. Be sure
you have set comspec in your environment.
<F3> - Twit
- This Key will set the callers access level to Zero (0) thus banning him from
entering you system forever. VD exits with errorlevel 18. Use this with
caution and prudence.
<F4> - Abort
- This key simply aborts VD and exits with a DOS errorlevel 15.
<F5> - HangUp
- This key disconnects the user and exits with a DOS errorlevel 16.
<F10> - Advertisement
- This key interrupts ValidOOR processing with an advertisement.
Local Mode
ValidOOR has a Local Mode that a sysop can use for testing purposes. You must
exit (type 15 or 7) from the BBS (in local) for it to work. VD can tell from
Exitinfo.Bbs that you are in LOCAL mode and will react accordingly. While in
Local mode, VD will not check to see if the phone number exists in the User
Directory file. This will allow you to test as many times as you like without
having to delete yourself from the User Directory every time.
In local mode, VD will skip the dialing and jump straight to Connection and
attempt to validate you. Your phone number will be written into the User
Directory if you pass the validation.
ERRORLEVELS
Several cases will cause ValidOOR to abort with an errorlevel:
* absence of any of these files: errorlevel=1
EXITINFO.BBS
VD.CFG
* User Not Validated errorlevel=2
* SysopName missing in VD.CFG errorlevel=3
* Duplicate Phone Number (in directory file) errorlevel=4
* User Abort at Menu errorlevel=5
* Absence of FOSSIL Comm Driver errorlevel=6
* Long Distance attempt (if enabled) errorlevel=7
* Inactivity errorlevel=8
* Carrier Loss errorlevel=9
* VOICE connect detection errorlevel=10
* Bad Number detected (BadNumber Control File) errorlevel=11
* Bad KEY file errorlevel=12
* Invalid # of Command Line Args errorlevel=13
* User Edited invalid number errorlevel=14
* F4 Abort key errorlevel=15
* F5 Hangup key errorlevel=16
* Beta Copy expired (betas ONLY) errorlevel=17
* Twitted the current user errorlevel=18
* FATAL System ERROR errorlevel=19
* Non-registered User running BETA version errorlevel=20
* If the user is validated successfully, ValidOOR will exit with an
errorlevel of 0.
These errorlevels are enabled in this release. They are not guaranteed to
remain the same in future versions. You can take advantage of these
errorlevels by trapping them all in your batch file and using the traps to
generate entries in your log to give you a more verbose explanation of what
went on.... be creative. You can use them any way you like.
Your KEY file
The ValidOOR Key file eliminates the 30 second delay at the beginning of the
program. You must register ValidOOR in order to get a key from me. I can
send the key via FidoNet mail or US Mail (Snail Mail). Please specify which
method you prefer when registering ValidOOR.
Reporting Bugs
If you have a problem with ValiDOOR you should report it immediately to me.
When making a bug report, please include the following info in a ZIPPED file:
A detailed description of the problem
A copy of your VD.CFG file
A copy of your log showing the problem if applicable
A copy of your UserDir if applicable
A copy of your badnumbr.ctl file if applicable
Without this info, it will be nearly impossible for me to find the problem.
Help me to help you.
The best place to report a problem in on my support system listed here:
ValidOOR Support
The Boot Factory BBS
FidoNet 1:264/19
804-262-9289
I also try to read the RA_UTIL echo regularly but that is not guaranteed to be
true at any given time.
File Requests
Magic Filenames for File Requests from 1:264/19
FILES : master download file list F264-019.ZIP
NEWFILES : Files less than 30 days old
ABOUT : General Info File
VDR : latest version of ValidOOR - for RA
VDQ : " " " " " QuickBBS
VDU : VD_Util for vd.cfg, language and Userdir files
The following utils will ONLY work with a key.
VDP : VD_Pack - userdir packer for registered users
VDC : VD_Create - userdir creator for registered users
Credits
Thanks to the following individuals:
Continental Software - The RemoteAccess folks.
Robert Rosanio - who gave me the original idea.
Greg Dawson - for teaching me how to access FOSSIL.
Mike Janke - for his wonderful Exit code.
Jim Whitby - for Documentation and other Help.
Ed Greene - for his debugging help and reports.
Richard Alfoni - for his debugging help and reports.
Tom Meehan - Chief code basher/tester.
Ken Givens - Invaluable Suggestions and Help
Net 264 - for tolerance.
Also Thanks to the Beta Testers.... All of you.
Report ALL to:
Cabell Clarke
804-262-9289 DATA
FidoNet 1:264/19